home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIX Installation Tools & Overlays 1999 May
/
SGI IRIX Installation Tools & Overlays 1999 May - Disc 2.iso
/
relnotes
/
performer_eoe
/
ch5.z
/
ch5
Wrap
Text File
|
1999-04-19
|
135KB
|
3,103 lines
- 1 -
6. _C_h_a_n_g_e_s__f_r_o_m__P_r_e_v_i_o_u_s__R_e_l_e_a_s_e_s
This Chapter identifies incremental changes and enhancements
since IRIS Performer 2.0. Changes are presented in reverse
chronological order, with the most recent releases listed
first.
6.1 _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
6.1.1 _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
+o pfFrustum::makeOrtho() calculated incorrect near/far
clip plane values. This has been fixed (SCR 658920).
+o pfGetStage() could return incorrect values due to the
Performer clock being included in the process list.
This has been fixed (SCR 668773).
+o Channel-CULL callbacks registered from the .ct loader
could collide when used in multi-channel
configurations, resulting in the incorrect calculations
of texture coordinates. This regression has been fixed
(SCR 668222).
+o perfly, asdfly, and clipfly could not configure multi-
hyperpipe systems. This capability has been added (SCR
675711).
+o Draw statistics were only being accumulated for the
first pipe in a hyperpipe group. This has been fixed
(SCR 675517).
+o A garbage frame would sometimes be seen when using
texture from a DIVO source in Performer on Onyx2
systems with 'Reality' graphics. This was due to a
mismatch in Performer's automatic detection of graphics
type and has been fixed (SCR 671095).
+o The default displacement offset for coplanar polygons
was set too large for small frusta. This has been
fixed (SCR 625598, 670200). See below for
configuration details.
+o Several additional improvements to the multipass
algorithm used for projective texture pfLightSources
have been made in 2.2.5. In particular, the algorithm
now supports geometry with texture based transparency
(for example, a tree billboard).
- 2 -
6.1.2 _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
6.1.2.1 _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L__1_._1__g_l_P_o_l_y_g_o_n_O_f_f_s_e_t_(_)
This release modifies the routines used for coplanar polygon
displacement to one based upon the polygon offset
functionality in OpenGL 1.1. The changes apply to all
platforms using OpenGL 1.1 except the Impact series.
Users may revert to the prior (Performer 2.2) behavior by
setting the environment variable
PF_FORCE_EXT_POLYGON_OFFSET.
Likewise, users may choose to force the new functionality to
be used on Impact systems (despite known bugs at this time)
by setting the environment variable
PF_FORCE_ARB_POLYGON_OFFSET.
In case the results of the new offset behavior are not ideal
for a particular system or database, users may tune the
values set internally by IRIS Performer. The environment
variables PF_ARB_POLYGON_OFFSET_FACTOR and
PF_ARB_POLYGON_OFFSET_UNITS can be set to floating point
values which will then be used internally as arguments to
glPolygonOffset(). See the glPolygonOffset(3G) man page for
further details of the effect of these settings.
Although the OpenGL 1.1 glPolygonOffset() changes were
intended to resolve machine dependency issues, please note
that the ideal offset factor and units value may still vary
from system to system. The glPolygonOffset() values set by
IRIS Performer were chosen for typical database settings on
InfiniteReality systems and may require adjustment on other
OpenGL 1.1 systems, using the environment variables
described above.
6.2 _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
6.2.1 _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
+o The Performer signal handler would enter an infinite
loop if a process forked or sproc'd from the APP
process exited. This has been fixed (SCR 651566).
+o Setting the PF_LPOINT_BOARD environment variable to
enable emulation of calligraphic hardware (by using
standard raster light points) had no effect. This has
been fixed (SCR 615443).
- 3 -
+o Threading the lightpoint process caused a segmentation
fault. This has been fixed.
+o Models containing pfLightPoints with a NULL
pfLPointState could cause a segmentation violation on
O2 systems running IRIX 6.5.2. This has been fixed
(SCR 614274).
+o Several improvements to the multipass algorithm used
for projective texture pfLightSources have been made.
Colored spotlights now interact correctly with each
other. Note that the current algorithm does not
support geometry with texture based transparency (for
example, a tree billboard), and can only produce
translucent geometry on systems with multisampling
capability.
+o Several pfStats::query() tokens were unimplemented.
Most of the missing tokens can now be used to query
statistics. The following will still return an error:
+o PFSTATSVAL_CPU_SECS
PFSTATSVAL_CPU_GFX_SWAPBUFFERS
PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE
PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_HOST
PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_XFORM
PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_FILL
PFSTATSVAL_GFXPIPE_TIMES_SECS
PFSTATSVAL_GFXPIPE_TIMES_SECS_HOST
PFSTATSVAL_GFXPIPE_TIMES_SECS_XFORM
PFSTATSVAL_GFXPIPE_TIMES_SECS_FILL
+o IRIX 6.5 introduced support for the concurrent use of
shared arenas and POSIX threads (pthreads), however
there was an error in the GLX implementation which
prevented IRIS Performer applications from opening a
window if the pthread library was linked. The GLX
implementation in the IRIX 6.5.3 overlay has addressed
this problem, so IRIS Performer applications can now be
safely used with pthreads.
+o The CSB loader has been updated to enable the use of
ClearCoat(tm).
+o Graphics state information could "leak" from a
cliptexture to other models in the scene. This has
been fixed (SCR 603185).
- 4 -
6.2.2 _N_e_w__F_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
6.2.2.1 _S_u_p_p_o_r_t__f_o_r__D_P_L_E_X__o_p_t_i_o_n
Performer 2.2.4 includes support for the DPLEX option to
Onyx2 Infinite Reality. This support has been affected
without changes to the API, and modifications to the
command-line options for perfly, clipfly, and asdfly have
been made to enable DPLEX. There are, however, some changes
to the semantics of _p_f_P_i_p_e, _p_f_P_i_p_e_W_i_n_d_o_w, and _p_f_C_h_a_n_n_e_l
interaction. This change is described below.
Initialization of the hyperpipe is via the existing
pfHyperpipe() API. This call defines the number of _p_f_P_i_p_es
to combine into a single hyperpipe. Each call to
pfHyperpipe() defines a separate hyperpipe instance. For
example, two calls to pfHyperpipe() with an argument of 2
would define two hyperpipes of 2 _p_f_P_i_p_es each to Performer.
Like pfMultipipe(), this routine can only be invoked prior
to pfConfig(). Additionally, the _p_f_P_i_p_es of the hyperpipes
will be the lowest numbered _p_f_P_i_p_es, with any non-hyperpipe
_p_f_P_i_p_es appearing at the end.
The first (lowest numbered) _p_f_P_i_p_e of the hyperpipe is the
master. In the above example, that would be _p_f_P_i_p_es 0 and
2. All control of the hyperpipe should be made through the
master _p_f_P_i_p_e. For example, to construct a _p_f_P_i_p_e_W_i_n_d_o_w for
a hyperpipe, the application can simply create it on the
master _p_f_P_i_p_e. The cloned _p_f_P_i_p_e_W_i_n_d_o_ws for each _p_f_P_i_p_e in
the hyperpipe will be created automatically. While allowed,
constructing a _p_f_P_i_p_e_W_i_n_d_o_w on a non-master pipe of the
hyperpipe will lead to undefined results.
Hyperpipes differ from other multipipe configurations in one
other very important way. The set of _p_f_C_h_a_n_n_e_l_s displayed on
the hyperpipe is shared amongst all of the _p_f_P_i_p_e_s in the
hyperpipe. That is, it is only necessary to create and set
_p_f_C_h_a_n_n_e_l objects on the master _p_f_P_i_p_e of the hyperpipe.
Since the hyperpipe is a time multiplexed view of these
channels, Performer will propagate changes in the _p_f_C_h_a_n_n_e_l
to each of the _p_f_P_i_p_e_s in turn.
The following code snippet identifies the steps needed to
setup a multi-hyperpipe config. It assumes that each of the
hyperpipes are symetric (i.e., have the same number of
pipes), although this is not required by Performer.
////****
**** LLLLooooccccaaaallll ddddeeeeccccllllaaaarrrraaaattttiiiioooonnnnssss
****////
- 5 -
iiiinnnntttt iiii;;;;
ppppffffCCCChhhhaaaannnnnnnneeeellll**** mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn;;;;
ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn;;;;
////****
**** TTTThhhheeee ffffoooolllllllloooowwwwiiiinnnngggg aaaassssssssuuuummmmeeeessss tttthhhhaaaatttt hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr ooooffff
**** hhhhyyyyppppeeeerrrrppppiiiippppeeeessss ttttoooo ccccoooonnnnffffiiiigggguuuurrrreeee aaaannnndddd hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr
**** ppppiiiippppeeeessss ppppeeeerrrr hhhhyyyyppppeeeerrrrppppiiiippppeeee....
****////
iiiinnnntttt ppppiiiippppeeeeCCCCoooouuuunnnntttt ==== hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt****hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt;;;;
ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
ppppffffHHHHyyyyppppeeeerrrrppppiiiippppeeee((((hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt))));;;;
////****
**** CCCCoooonnnnffffiiiigggguuuurrrreeee PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr
****////
ppppffffCCCCoooonnnnffffiiiigggg(((())));;;;
////****
**** CCCCoooonnnnffffiiiigggguuuurrrreeee tttthhhheeee ssssccccrrrreeeeeeeennnnssss ffffoooorrrr tttthhhheeee ppppffffPPPPiiiippppeeeessss
****
**** AAAAssssssssuuuummmmeeeessss aaaallllllll ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy aaaannnndddd ssssccccrrrreeeeeeeennnn aaaassssssssiiiiggggnnnnmmmmeeeennnnttttssss tttthhhhaaaatttt mmmmaaaapppp
**** ttttoooo ppppffffPPPPiiiippppeeee nnnnuuuummmmbbbbeeeerrrr
****////
ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
ppppffffPPPPiiiippppeeeeSSSSccccrrrreeeeeeeennnn((((ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii)))),,,, iiii))));;;; //////// aaaassssssssuuuummmmeeeessss aaaallllllll oooonnnn ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy
////****
**** CCCCoooonnnnffffiiiigggguuuurrrreeee aaaa tttthhhhrrrreeeeeeee,,,, ttttwwwwoooo----ppppiiiippppeeee hhhhyyyyppppeeeerrrrppppiiiippppeeee ffffoooorrrr mmmmuuuullllttttiiii----cccchhhhaaaannnnnnnneeeellll ddddiiiissssppppllllaaaayyyy....
****////
ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii ++++==== hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt)))) {{{{
ppppffffPPPPiiiippppeeee**** pppp;;;;
ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** ppppwwww;;;;
ppppffffCCCChhhhaaaannnnnnnneeeellll**** cccchhhhaaaannnn;;;;
iiiinnnntttt sssshhhhaaaarrrreeee;;;;
PPPPFFFFVVVVEEEECCCC3333 xxxxyyyyzzzz,,,, hhhhpppprrrr;;;;
pppp ==== ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii))));;;;
ppppwwww ==== ppppffffNNNNeeeewwwwPPPPWWWWiiiinnnn((((pppp))));;;;
ppppffffPPPPWWWWiiiinnnnNNNNaaaammmmeeee((((ppppwwww,,,, """"HHHHyyyyppppeeeerrrrppppiiiippppeeee WWWWiiiinnnnddddoooowwww""""))));;;;
ppppffffPPPPWWWWiiiinnnnCCCCoooonnnnffffiiiiggggFFFFuuuunnnncccc((((ppppwwww,,,, OOOOppppeeeennnnPPPPiiiippppeeeeWWWWiiiinnnn))));;;;
ppppffffPPPPWWWWiiiinnnnTTTTyyyyppppeeee((((ppppwwww,,,, PPPPFFFFPPPPWWWWIIIINNNN____TTTTYYYYPPPPEEEE____XXXX))));;;;
ppppffffPPPPWWWWiiiinnnnFFFFuuuullllllllSSSSccccrrrreeeeeeeennnn((((ppppwwww))));;;;
ppppffffPPPPWWWWiiiinnnnMMMMooooddddeeee((((ppppwwww,,,, PPPPFFFFWWWWIIIINNNN____NNNNOOOOBBBBOOOORRRRDDDDEEEERRRR,,,, 1111))));;;;
ppppffffCCCCoooonnnnffffiiiiggggPPPPWWWWiiiinnnn((((ppppwwww))));;;;
iiiiffff ((((iiii ======== 0000)))) mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn ==== ppppwwww;;;;
cccchhhhaaaannnn ==== ppppffffNNNNeeeewwwwCCCChhhhaaaannnn((((pppp))));;;;
sssshhhhaaaarrrreeee ==== ppppffffGGGGeeeettttCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn))));;;;
sssshhhhaaaarrrreeee ||||==== PPPPFFFFCCCCHHHHAAAANNNN____VVVVIIIIEEEEWWWWPPPPOOOORRRRTTTT |||| PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS ||||
- 6 -
PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS____HHHHWWWW;;;;
ppppffffCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn,,,, sssshhhhaaaarrrreeee))));;;;
ppppffffMMMMaaaakkkkeeeeSSSSiiiimmmmpppplllleeeeCCCChhhhaaaannnn((((cccchhhhaaaannnn,,,, 44445555))));;;;
ppppffffCCCChhhhaaaannnnAAAAuuuuttttooooAAAAssssppppeeeecccctttt((((cccchhhhaaaannnn,,,, PPPPFFFFFFFFRRRRUUUUSSSSTTTT____CCCCAAAALLLLCCCC____VVVVEEEERRRRTTTT))));;;;
ppppffffAAAAddddddddCCCChhhhaaaannnn((((ppppwwww,,,, cccchhhhaaaannnn))));;;;
ppppffffSSSSeeeettttVVVVeeeecccc3333((((xxxxyyyyzzzz,,,, 0000,,,, 0000,,,, 0000))));;;;
ppppffffSSSSeeeettttVVVVeeeecccc3333((((hhhhpppprrrr,,,, ((((((((hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt----1111)))) **** ....5555ffff
---- iiii////hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt )))) **** 44445555....ffff,,,, 0000,,,, 0000))));;;;
ppppffffCCCChhhhaaaannnnVVVViiiieeeewwwwOOOOffffffffsssseeeettttssss((((cccchhhhaaaannnn,,,, xxxxyyyyzzzz,,,, hhhhpppprrrr))));;;;
iiiiffff ((((iiii ======== 0000))))
mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn ==== cccchhhhaaaannnn;;;;
eeeellllsssseeee
ppppffffAAAAttttttttaaaacccchhhhCCCChhhhaaaannnn((((mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn,,,, cccchhhhaaaannnn))));;;;
}}}}
The remainder of the code should follow a typical multipipe
application.
There are certain restrictions on usage of _p_f_P_i_p_es,
_p_f_P_i_p_e_W_i_n_d_o_ws and _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_ls when running in
hyperpipe mode. All actions (with the exception of graphics
pipe specific controls, e.g., pfPWinFBConfigAttrs() and
pfPWinFBConfigId) should occur on those objects associated
with the master _p_f_P_i_p_e. In those instances where pipe
specific attributes need modification, the appropriate
pfPipeWindow or pfPipeVideoChannel can be obtained using the
indexed pfGetPipePWin and pfGetPWinPVChan functions. The
index should equal the index of the associated master object
on the master pipe.
There is a limitation in that changes to _p_f_P_i_p_e_W_i_n_d_o_ws
affected by the draw process will not be propagated to other
_p_f_P_i_p_e_W_i_n_d_o_ws in the hyperpipe. Also, statistics drawn by
the _p_f_F_r_a_m_e_S_t_a_t_s will reflect only the times for a
particular draw process and not the entire hyperpipe. These
problems may be removed in a later release.
6.3 _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3
6.3.1 _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3
+o Performer 2.2 always used the channel frustum for
culling when PFCULL_GSET was set, even if a custom cull
frustum polytope was defined. This has been fixed.
(SCR 635693)
+o Attempting to delete a cliptexture could cause a core
dump. Cliptexture deletion is not supported, so a
DEBUG-level warning is now emitted. (SCR 594276)
- 7 -
+o Fully transparent pfLPointStates could cause
segmentation violations in Performer 2.2. This has
been fixed. (SCR 614274)
+o The FLT loader printed assertion failures such as the
following:
+o pfdConverterMode_flt: user data slot cannot be set
to 1
+o pfdConverterMode_flt: private user data slot
cannot be set to 2
The cause of these problems has been fixed. (SCR
624177)
+o pfdFindConverterDSO was unable to locate the 3ds file
loader. This was the result of conflicting IL and IFL
versions and has been fixed. (SCR 625838)
+o The warning "pfTexture::compare(): pfClipTexture is not
a pfTexture" was emitted when comparing a pfGeoState
with cliptexture to one with a regular texture. This
has been fixed. (SCR 626001)
+o Picking with orthographic viewing frusta returned
incorrect hit points. This has been fixed. (SCR
601650)
+o Color fields in pfGeoSets were not being handled
correctly during the print traversal. This has been
fixed. (SCR 621124)
+o pfuTravCalcBBox in trav.c did not calculate the
bounding box for pfBillboard nodes. It now does. (SCR
632225)
6.4 _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2
6.4.1 _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2
+o _p_f_B_i_l_l_b_o_a_r_d_s were always using Z axis (Bug #591154)
+o _p_f_P_i_p_e_W_i_n_d_o_w _r_e_s_i_z_e _w_i_t_h _f_o_r_k_e_d _c_u_l_l caused per-frame
slow X communication. (Bug #611816)
+o _p_f_T_e_x_t_u_r_e _w_i_t_h _T_e_x_L_O_D _s_e_t_t_i_n_g_s would leak memory. (Bug
#600949)
- 8 -
+o _p_f_U_n_r_e_f_D_e_l_e_t_e() would delete an object when its ref
count was decremented to 65536. This has been fixed,
and the types of pfGetRef() and pfUnrefGetRef() have
been changed from ushort to int. (Bug #603177)
+o The _l_o_o_k_a_h_e_a_d directive was ignored in no-imagecache
._c_t _c_l_i_p _t_e_x_t_u_r_e _c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s. _N_O_T_E: since this
is fixed, applications using .ct files containing a
lookahead command may use much more memory, and may
have to be re-tuned (or the lookahead command removed).
(Bug #576096)
+o The CSB loader has been updated to enable loading of
files created by OpenGL Optimizer 1.2
+o The FLT loader has been updated to version 15.4g (Bug
#615990). Several bugs have been fixed, including:
+o A bug in revision R15.4fi where
pfuTexGenClipCenterNode was inserted as parent of
root node. In such cases the clip texture was not
centered.
+o A bug in revision R15.4fi where the loader's user
data slot was not initialized. This caused core
dumps when certain run-time features were enabled
such as clip planes, behaviors, and adaptive light
points.
+o _P_r_o_j_e_c_t_e_d _t_e_x_t_u_r_e_s behaved improperly when using
multiple channels or when lighting was off. (Bugs
#581332, #581334)
+o _I_n_f _f_r_a_m_e _r_a_t_e _r_e_p_o_r_t_e_d _f_o_r _I_n_t_e_r_l_a_c_e_d _v_i_d_e_o
_f_o_r_m_a_t_s. Now, the current swap rate will be
reported which for interlaced video formats might
be faster than the requested frame rate (ie.
60/30Hz). (Bug #603567).
+o _v_i_s_f_l_y _d_e_m_o was unable to start due to an
unresolvable symbol in the compat libraries,
pfuCalcNormalizedChanXY (Bug #600942)
+o _B_a_d _L_i_g_h_t_i_n_g - the 2.0.6/2.1.4 compat libraries
had bad lighting characteristics; all lit models
were shaded grey (Bug #598903)
+o _p_f_d_F_i_n_d_C_o_n_v_e_r_t_e_r_D_S_O() in 2.0.6/2.1.4 was failing
due to a lookup problem in pfdLoadFile. (Bug
#605958)
- 9 -
+o _6_4_b_i_t _o_p_e_r_a_t_i_o_n _w_i_t_h _I_R_I_X _6._5 could fail with IRIS
Performer 2.0 and 2.1 libraries. This is fixed in
the IRIS Performer libraries that were shipped
with IRIX 6.5 and also in the 2.0.7/2.1.5
libraries.
6.5 _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1
6.5.1 _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1
+o _a_s_d_f_l_y _z_b_u_f_f_e_r _p_r_o_b_l_e_m_s _o_n _i_R due to a lose layer
offset call in asdfly/terrain.c. (Bug #575993)
+o _M_u_l_t_i_p_i_p_e _C_a_l_l_i_g_r_a_p_h_i_c_s supports 10 pipes instead of
just 3. (Bug #559773)
+o _M_u_l_t_i_p_i_p_e _p_f_G_e_t_S_c_r_e_e_n() _r_e_t_u_r_n_i_n_g (-_1)_i_n _d_r_a_w _s_t_a_g_e
_c_a_l_l_b_a_c_k _i_n_i_t..
+o _O_p_e_n_W_o_r_l_d_s _V_R_M_L _2._0 (._w_r_l) _l_o_a_d_e_r failed for N32 and
N64 due to default library search path
(/usr/lib[32,64]. (Bug #575792)
+o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _w_i_t_h _a_u_t_o_m_a_t_i_c _c_l_i_p_t_e_x_t_u_r_e
_c_e_n_t_e_r_i_n_g could dump core if pfuInit() was not called
by the application before pfConfig(). (Bug #575589)
+o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _u_s_i_n_g _n_e_w _1_5._4 _f_e_a_t_u_r_e_s could
dump core due to lack of initialization of user data
slot used for behaviors and clip planes. (Bug #575586)
+o _X_s_g_i_v_c _V_i_d_e_o _C_h_a_n_n_e_l _0 had to exist or Performer would
hang on startup. This also caused hangs on OCTANE OCO
(multi-channel operation). (Bug #577815)
+o _N_6_4 _V_i_d_e_o _c_h_a_n_n_e_l _o_p_e_r_a_t_i_o_n_s would dump core (Bug
#575616). To see this fix on IRIX 6.2 or IRIX 6.4,
additional X and GL patches are required.
+o _I_n _O_c_t_a_n_e _O_C_O _m_o_d_e _o_r _n_o _v_i_d_e_o _c_h_a_n_n_e_l would result
in no pfPipeWindow being opened. (Bug #577065).
+o _D_V_R _s_h_o_w_i_n_g _n_o_i_s_e _o_n _b_o_t_t_o_m _l_i_n_e_s _o_f _v_i_d_e_o. (Bug
#577976).
+o _p_f_i_S_p_h_e_r_i_c _m_o_t_i_o_n _m_o_d_e_l _t_r_a_n_s_i_t_i_o_n (rail) tracking was
too fast for really slow speeds (in the range of
0.000001). (Bug #583127).
- 10 -
6.5.2 _P_r_o_b_l_e_m_s _f_i_x_e_d _i_n _2._0._6 _a_n_d _2._1._4 (_s_h_i_p_p_e_d _w_i_t_h
_2._2._1)
+o _p_f_u_C_o_n_f_i_g_M_C_O now properly initializes multiple channels
on multiple pipes. (Bug #564062)
+o _p_f_W_i_n_d_o_w::_g_e_t_F_B_C_o_n_f_i_g_A_t_t_r_s() was core dumping on
pbuffers. It will now return NULL for a pbuffer since
the attribute arrays is for XVisuals and pbuffers
require GLXFBConfigSGIXs which should be specified with
pfWindow::setFBConfig(). (Bug #575989)
+o _p_f_u_S_a_v_e_I_m_a_g_e _i_n _N_6_4 didn't work due to bad pointer
types in libpfutil/snapwin.c. (Bug #575243)
+o _N_6_4 _p_l_a_c_e_m_e_n_t _o_f _p_f_D_a_t_a_P_o_o_l_s could cause brk to run out
of space for heap area. (Bug #575065)
6.6 _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2
6.6.1 _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._0_._4__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._0_._5__a_n_d__2_._2
+o _p_f_I_n_i_t_C_l_o_c_k in 250MHz IMPACT use not to be consistent.
+o _P_i_c_k_i_n_g models with LOD unded DCS used to fail with
large DCS translations (bug#455490)
+o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
texture.
+o _p_f_B_o_x contains function has been fixed
+o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
dump if the application store double float in the
datapool.
+o Some _q_u_e_r_y feature request were missing, 2.0.5 is now
at the same level as 2.2.
+o Assigning a Drawable without a visual used to cause the
window not to open. (bug# 450891)
+o Full screen had a window border when compiling for N64.
(bug #542372)
+o _p_b_u_f_f_e_r were not fully supported.
- 11 -
6.6.2 _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._1_._2__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._1_._3__a_n_d__2_._2
+o When the first video channel on a graphic pipeline was
not active, _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_l was failing under forked
DRAW multi-process.
+o _A_S_D _T_e_r_r_a_i_n was not supporting dynamic paging. This
fixed so ASD tiles can be dynamically paged in the
DBASE prmcess.
+o _A_S_D _T_e_r_r_a_i_n was not working on multipipe. This is fixed
and ASD works fine with multiple pipes/channels. _a_s_d_f_l_y
is fixed as well.
+o _V_e_r_t_e_x _a_r_r_a_y_s used in a GL display list used to produce
invalid normals. This has been fixed in OpenGL with
patch 1808 or later.
+o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
texture.
+o _p_f_B_o_x contains function has been fixed
+o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
dump if the application store double float in the
datapool.
+o Full screen had a window border when compiling for N64.
(bug #542372)
+o Some _q_u_e_r_y feature request were missing, 2.1.3 is now
at the same level as 2.2.
+o _M_o_t_i_f decoration hints used not to work in 64 bits N64.
6.6.3 _O_t_h_e_r__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._2
+o _I_n_v_e_n_t_o_r loader used not to work N32/N64. (bug# 434322)
+o _G_a_n_g_S_w_a_p was not working at all for OpenGL. This is
fixed in performer and in OpenGL after patch 1808.
+o _p_e_r_f_l_y did not accept input from other screens than the
master screen. (bug# 459186)
+o _E_a_r_t_h_S_k_y used not to propagate the right fog values in
sync to all screens in multipipe mode (bug# 437747)
- 12 -
+o _s_h_a_d_o_w _t_e_x_t_u_r_e_s used not to be implemented for
InfiniteReality/OpenGL.
+o _p_f_c_o_n_v did core dump or go in infinite loop when
converting some inventor files. (bug# 435232)
+o _g_l_o_b_a_l _s_t_a_t_e used not to work properly and be in
conflict with channel state (see option -q0 in perfly).
(bug# 423829)
+o _B_i_n_s used to have many problems. Bin number had to be
in successive numbers (bug# 416557), bin Order had no
effect at all, there was no way to draw the objects
that are not falling into a bin (can be done in 2.2
using pfDrawBin(-1)), there was no way to know which
bins are in used (pfGetFreeBin() gets that information
in 2.2). Note that 2.2 has a predefined #3 bin: the
Light Point bin, and that this bin has a very special
behavior and cannot be used for general purpose.
+o _p_f_A_S_D used to only handle terrain with less than 65000
vertices.
+o _p_f_d_B_u_i_l_d_A_S_D used to have memory corruptions.
+o _D_V_R used to produce garbage when used on a screen
larger than 1280 pixels. Performer now prevent scaling
in X direction as the hardware does not support it. It
is not going to be fixed in OpenGL, it is a HW
bandwidth limitation.
+o _g_l_N_o_r_m_a_l_i_z_e was turned on by default, resulting in a
minimal loss of performances. Now it is automatically
turned on only when the current transformation matrix
includes scaling, and turned off otherwise.
+o Some _p_f_M_a_t_h routines were slower than system libmath
routines that are now very optimized. The corresponding
pfMath routines are replaced by a #define that calls
system math routines directly.
+o _C_l_i_p_t_e_x_t_u_r_e have been upgraded to production standards
for IRIS Performer 2.2. The core cliptexture
functionality has been respecified to tighter
tolerances, critical functionality such as load control
and virtual cliptextures has been added, and additional
API in libpfutil and libpfdu has been put in to make
cliptextures easier to use in production applications.
+o _p_e_r_f_l_y -_t now allows specification of visual ID for
each pipe as a comma-separated list.
- 13 -
+o _p_f_F_o_n_t._h in previous versions was missing some internal
fields in the class declaration that would cause
problems for C++ user code creating pfFont structures
and the allocates structures would not be the proper
size.
6.6.4 _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._0_/_2_._1
IRIS Performer 2.1 is an enhanced version of the IRIS
Performer 2.0 release designed in conjunction with the Onyx
InfiniteReality graphics hardware. It is, in essence,
"Performer 2.0 with InfiniteReality extensions." Unlike IRIS
Performer 2.1 that was only for InfiniteReality, the new
IRIS Performer 2.2 is an enhanced version of IRIS Performer
2.0/2.1 that runs on all SGI plateformes, enabling hardware
specific features (DVR, ClipMapping) only when supported
directly by the Graphic Subsystem. IRIS Performer 2.2 has
numerous improvements and new features over 2.0/2.1 such as
pfFlux, pfb/pfi file formats, compute process for ASD,
Calligraphic light support.... IRIS Performer 2.0 API is
almost unchanged into 2.2, but it is not the case for 2.1 as
the ClipMapping and ASD have had a lot of API changes.
6.6.4.1 _C_l_i_p_T_e_x_t_u_r_e
InfiniteReality supports very large textures through a
virtual mipmapped texture scheme we call cliptexturing. Here
is a preview of the basic concepts.
Clip Textures provide a way use texture maps too large to
hold in graphics texture memory. Until now, to use a large
texture, you had to break it into tiles, bringing in the
next texture as you approached a tile boundary. This
approach has numerous problems, including what to do about
polygons that span texture tile boundaries, properly
handling the changes in texture coordinates, doing
MIPMapping without visual artifacts, etc. Performer Clip
Textures solve these problems. They allow you to seamlessly
use a very large texture, letting performer handle the
loading issues. Since it is one continuous texture, there
are no problems with texture seams or changes in texture
coordinates.
A clip texture can be thought of as a very large mipmapped
texture. The dimensions of level 0, the highest resolution
level of the texture, is the clip texture's *virtual size*.
For any given scene, only a subset of the entire clip
texture is visible to the observer. pfClipTextures augment
pfTextures by adding the notion of a center, a location in
- 14 -
texel space that is close to the observer. As the center
moves, the cliptexture must repeatedly applied, to update
the texels in texture memory, so that contains the texels
surrounding the current center.
With the center properly updated, only a subset of the
entire cliptexture need be loaded into texture memory at any
given time. The visible region of this texture is called the
*clip region*. The contents of this region are updated as
the cliptexture center changes, always keeping the
surrounding texel data available to the texturing hardware.
The clip region can be visualized as a fixed width square
column cutting through the mipmap levels. At the coarsest
levels, where the MIPmap level becomes smaller than the clip
region size, the cliptexture is a normal MIPmap pyramid. As
the center moves on level 0, the column shears so that it
surrounds the center, each level moving half as fast as the
finer level above it.
The texture itself is stored on disk and system memory as
*tiles*. One or more tiles are stored as *texture tile
files* on disk, and are brought into system memory as
needed. A cache of these tiles, called the *memory region*
is kept in system memory to reduce disk latency. A subset of
the memory region texels, the *texture region* are
downloaded to the graphics hardware texture memory.
Each level of the clip texture larger than the clip size is
contained in an level updated with the proper texel data,
based on the center position at that level. The image cache
must download texel data as tiles from the appropriate
texture data files, keeping the mem region updated, and use
texture subloads to update texel data from the texture
region into proper area of hardware texture memory. The
clip texture itself is composed of image caches and image
tiles. The image tiles describe the levels of the mipmap
pyramid that are equal to or smaller than the clip region.
It updates the clip texture center, and commands the image
caches to reapply the texture memory as the center changes.
The application can configure a clip texture by loading
_c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s, contains information about the texel
data, cliptexture sizes, and texture file names and
locations. A configured cliptexture can be used in the scene
graph like a normal pfTexture. The application can attach
mpcliptextures to cliptextures, and pipes to mpcliptextures
automates the cliptexture apply process each frame, and
allows cliptexture updates to be done in the application
process. Every frame, the application updates the
mpcliptexture _c_l_i_p_m_a_p _c_e_n_t_e_r. This can be automated by
adding _c_e_n_t_e_r _n_o_d_e_s nodes to the scenegraph.
- 15 -
Cliptextures have a load control feature called Dynamic
Texture Resolution (DTR). This feature allows clipmaps to be
roamed faster than the system bandwidth would normally
allow. DTR accomplishes this by improving the order in which
tiles are download into image caches, and selectively
blurring the cliptexture and adjusting the effective
clipsize in order to modulate the cliptextures bandwidth
requirements. DTR is controlled through a mode bitmask,
which is used to enable or disable various load control
features, and by a set of parameters that can be adjusted by
the application to tune load control performance.
There is a special form of clipmaps, called virtual
clipmaps, which can be used to exceed some of the
limitations in maximum virtual size and number of levels
inherent in the system hardware. Virtual clipmaps trade off
larger possible cliptextures against increased complexity,
and additional interactions between the cliptexture and the
scenegraph. With virtual cliptextues, the cliptexture,
itself a virtualization of a MIPmap, is itself virtualized.
The physical cliptexture is roamed within a larger virtual
cliptexture in three dimensions; s, t, and level of detail
(LOD). This roaming is controlled by setting the center and
adjusting the virtualLOD offset. The number of physical
clipmap levels in use is controlled by adjusting the
effective levels parameter. When many levels need to be
accessed, the virtuallodoffset and other parameters can be
dynamically modified as the scenegraph is traversed, trading
off some performance for much wider range of available LOD
levels.
Man pages to see: pfClipTexture, pfQueue, pfImageTile
Demos to check out:
/usr/share/Performer/data/clipdata/hunter/run_hl
/usr/share/Performer/data/clipdata/moffett/run_mof
Sample programs to check out:
/usr/share/Performer/src/pguide/libpr/icache.c
/usr/share/Performer/src/pguide/libpr/icache_mwin.c
/usr/share/Performer/src/pguide/libpf/cliptex.c
/usr/share/Performer/src/sample/C/perfly
Utilities to use:
/usr/share/Performer/src/libpfutil/cliptexture.c
/usr/share/Performer/src/libpfutil/clipcenter.c
- 16 -
ClipTexture Texture Data and Configuration Files:
/usr/share/Performer/data/clipdata/hunter
/usr/share/Performer/data/clipdata/moffett
*.ic - image cache configuration files
*.ct - cliptexture configuration files
6.6.4.2 _V_i_r_t_u_a_l__c_l_i_p_t_e_x_t_u_r_e_s
Virtual cliptextures of up to 1<<23 (8 million) texels on a
side are supported by IRIS Performer 2.2. This allows a
real cliptextures (currently limited in size by the
InfiniteReality hardware to at most 32Kx32K texels) to be
embedded in a larger virtual clipmap of up to 8Mx8M texels.
The application controls the position of the real
cliptexture within the virtual cliptexture by updating the
center and the _v_i_r_t_u_a_l _L_O_D _o_f_f_s_e_t. The offset adjusts the
real cliptexture in the LOD direction. The real cliptexture
can only occupy positions that are valid subsets of the
virtual cliptexture. The number of valid locations can be
increased by using less _e_f_f_e_c_t_i_v_e _l_e_v_e_l_s The real
cliptexture will automatically be centered around the
current center of the virtual cliptexture, which the
application sets on a per-frame basis (see above).
Utilities are provided for intelligently selecting where to
offset the real clipmap within the virtual clipmap each
frame. For details, see the source code for
pfuCalcSizeFinestMipLOD in libpfutil, and play with the
"Clip LOD Offset" slider in perfly when viewing a clip
texture bigger than 32Kx32K.
6.6.4.3 _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n
A pfASD is a pfNode which can handle very large terrain
surfaces that are described as multiple LODs. Active
Surface Definition accuratedly describes different portions
of the terrain using triangles from different LODs. The
multiple LODs have a coherent subdivision-surfaces-like
relationship between the neighboring levels. pfASD contains
a small scene graph that is generated dynamically to reflect
the current visible geometry being rendered.
These routines implement the Active Surface Definition (ASD)
feature. ASD defines a hierarchical structure that
organizes all the LODs of a terrain. At run-time, ASD
traverses the structure, selecting triangles from different
- 17 -
LODs to render the portion of the terrain that is within a
volume of interest. Triangles are rendered either at their
pre-stored locations, when they are in a particular LOD
range, or at computed morphed locations, when they are
within the morphing zone of a LOD range. There will be other
ways to evaluate the terrain other than purely range based
approach. The way to evaluate each vertex is the "evaluation
function". The evaluation function can be defined as a user
call back function, when the default range based evaluation
is not appropriate.
An example of a user defined callback function can be found
in
/usr/share/Performer/src/sample/C/asdfly/eval_function.c
pfASD has its own thread when user claimed multiprocessing
mode, e.g. PFMP_FORK_COMPUTE. Asychronizely, the evaluation
of the structure is done in the thread and the created
geometry (active mesh) are merged into the scenegraph
internal to pfASD at pfFrame time. pfASD enlarges the
viewing frustum to accommodate the delay of evaluation.
The cull of pfASD is handled together with the evaluation.
In another word, the gsets that are generated by evaluation
is the set of triangles that should be or soon to be
visible.
pfASD handles multichannel evaluation and ensures that
neighboring channels will have consistently connected
triangles. A channel can also share the evaluated active
mesh from another channel using pfChannel::ASDattach. pfASD
handles multipipe as well.
6.6.4.4 _F_l_u_x__a_n_d__E_n_g_i_n_e
A _p_f_F_l_u_x is a container for holding dynamic data. It
contains multiple buffers of data each associated with a
frame number. This allows multiple processes to each have a
copy of the data appropriate to the frame they are working
on. A full pfGeoSet can be fluxed pfFlux should be used
instead of pfCycleBuffer as they do not require a copy of
the data to be done to synchronize the stages of the process
pipeline.
A _p_f_E_n_g_i_n_e is an object that controls the dynamic data in a
pfFlux. A pfEngine of type PFENG_MORPH associated with a
pfFlux replaces a pfMorph node.
- 18 -
see _p_f_F_l_u_x, _p_f_E_n_g_i_n_e, _p_f_F_S_C, _p_f_S_w_i_t_c_h and _p_f_L_O_D man pages.
6.6.5 _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._1
6.6.5.1 _C_l_i_p_M_a_p_p_i_n_g
_p_f_I_m_a_g_e_C_a_c_h_e renamed some API calls (the corresponding gets
are not shown)
wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeOOOOrrrriiiiggggiiiinnnn
nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnOOOOrrrrgggg
wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeSSSSiiiizzzzeeee
nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnOOOOrrrriiiiggggiiiinnnn
nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnOOOOrrrrgggg
wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDsssstttt
nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxx
wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDssssttttSSSSiiiizzzzeeee
nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxSSSSiiiizzzzeeee
wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVViiiirrrrttttuuuuaaaallllSSSSiiiizzzzeeee
nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeIIIImmmmaaaaggggeeeeSSSSiiiizzzzeeee
oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCeeeennnntttteeeerrrr
oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMaaaaxxxxUUUUppppddddaaaatttteeeeSSSSiiiizzzzeeee
- 19 -
nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccTTTTeeeexxxxRRRReeeeggggiiiioooonnnn
nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccMMMMeeeemmmmRRRReeeeggggiiiioooonnnn
_p_f_Q_u_e_u_e as new functionality
nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttMMMMooooddddeeee
nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttFFFFuuuunnnncccc
nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
nnnneeeewwww:::: ppppffffGGGGeeeettttQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD
_p_f_I_m_a_g_e_C_a_c_h_e now use sorting queus Image cache configuration
files have a version2.0 format. The parser will run with
either format. The new format is a little more robust and
easier to use. The parser also now calls separate pfutil
functions that do the creation and configuration work. This
will make it easier to create custom configuration routines.
The configuration files now support relative pathnames.
Cliptexture configuration files can now be created that
don't need image cache configuration files.
6.6.5.2 _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n
_l_i_b_p_f_s _n_o _l_o_n_g_e_r _e_x_i_s_t_s. You should make sure you no longer
link with it. pfTerrain no longer exists either. All
PFTERRAIN_ tokens have been renamed PFASD_. Aligning object
to pfASD uses pfFlux and pfEngine.
ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ****ggggssss))))
is now
ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ********ggggssss,,,, iiiinnnntttt nnnnuuuummmm))))
It is important that when you port to this new api you use
pfMalloc to allocate the array of pfGeoState pointers.
So:
ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((aaaassssdddd,,,, ggggssss))));;;;
Should become:
- 20 -
{{{{
ppppffffGGGGeeeeooooSSSSeeeetttt ********ggggssssssss;;;;
ggggssssssss ==== ((((ppppffffGGGGeeeeooooSSSSeeeetttt ********))))ppppffffMMMMaaaalllllllloooocccc((((ssssiiiizzzzeeeeooooffff((((ppppffffGGGGeeeeooooSSSSeeeetttt********))))****1111,,,,
ppppffffGGGGeeeettttSSSShhhhaaaarrrreeeeddddAAAArrrreeeennnnaaaa(((())))))));;;;
ggggssssssss[[[[0000]]]] ==== ggggssss;;;;
ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((aaaassssdddd,,,, ggggssssssss,,,, 1111))));;;;
}}}}
PFTERRAIN constants have become PFASD constants pfs prefix
has become pfASD pfsFace data structure has become pfASDFace
and the field names have been changed to properly reflect
the functionality.
A current version of the Muligen loader is supplied to
handle these changes
New sample programs including examples of aligning features
and moving objects to ASD geometry.
/usr/share/Performer/src/pguide/libpf/C/ASD_align.c
New sample program that demonstrates the pfASD data
structure
/usr/share/Performer/src/pguide/libpf/C++/simpleASD.C
pfASD can be paged in as simle areal blocks, as handled by
Multigen CAT feature.
pfASD also supports a multi-resolution paging scheme, very
similar to clipmap paging. An example of the construction of
pfASD from a set of uniform elevation data can be found in
/usr/share/Performer/src/lib/libpfdu/pfdBuildASD.c
Inside the same file, you can find routines that constructs
paging ASD tiles from a fully built ASD structure. Please
notice that the builder is for demonstration purposes
mainly. The algorithm used is not sophisticated enough to
provent terrain from visible morphing distortion during
real-time fly through. The demo "yosemite" provided on 2.2
demo CD is constructed using CAT feature in Multigen.
Paging construction example can be found in
/usr/share/Performer/src/pguide/libpf/C/buildarcinfo.c
/usr/share/Performer/src/pguide/libpf/C/buildbw.c
/usr/share/Performer/src/pguide/libpf/C/builddem.c
/usr/share/Performer/src/pguide/libpf/C/builddted.c
- 21 -
Executing the command, e.g.
buildbw elevation.bw bw/tile bw/config bw/page
will put a set of paging tiles under the directory bw, with
prefix "tile" as their file names. Once you decide on how
many extra tiles to page on each LOD based on LODRange as
well as the paging delay, you MUST process the tiles one
more time into a fast paging binary format before feeding it
into a paging pfASD node.
The second pass paging data construction can be found in
/usr/share/Performer/src/pguide/libpf/C/convasd.c
For example,
convasd bw/config bw/page
will process the tiles. The final step is to hand all the
attributes defined in the config file and page file to pfASD
by calling
pfdLoadConfig(config, page);
6.6.5.3 _O_p_e_n_G_L__V_e_r_t_e_x__A_r_r_a_y_s
The OpenGL _V_e_r_t_e_x_A_r_r_a_y extension is supported by IRIS
Performer as an optimized way to send formatted data to the
graphics pipeline, reducing the host interface.
Vertex arrays use a new pfGSetAttr list, PFGS_PACKED_ATTRS,
that includes a separate copy of the vertex attribute data
packed into a single non-indexed array. Your vertex
coordinates may optionally be in this packed array. A
sample program that demonstrates the use of vertex arrays on
pfGeoSets is in:
/usr/share/Performer/src/pguide/libpr/packedattrs.c
Additionally, there is a utility traversal,
pfuTravCreateVertArrays, that will traverse the scene graph
and create vertex arrays for the pfGeoSets and optionally
pfDelete the other redundant attribute arrays. The utility
routines used by this traversal to actually pack the
pfGeoSet data is pfuFillGSetVertArray(). This traversal
can be invoked on the Perfly sample application with the -v
# option where # is 1 or 2 to select one of two packed
formats of with or without the vertices copied into the
- 22 -
vertex array, respectively.
6.6.5.4 _O_p_e_n_G_L__s_p_l_i_n_e__F_o_g
InfiniteReality supports the specification of a fog function
so Spline Fog support for OpenGL has been added to IRIS
Performer and will be available on machines that support it.
6.6.5.5 _T_F_a_n_s
IRIS Performer 2.2 supports Triangle Fans in a pfGeoSets
when using OpenGL
6.6.5.6 _A_s_y_n_c_h_r_o_n_o_u_s__D_y_n_a_m_i_c__D_a_t_a
IRIS Performer 2.2 supports truly asynchronous dynamic data
with _p_f_F_l_u_x. Data for geometry attributes in pfGeoSets and
fields in various pfNodes can be computed in fully
asynchronous processes and store in a pfFlux buffer. pfFlux
will manage the the hookup, data exclusion, and frame
management accurate book-keeping. pfFluxes can be
explicitly driven by _p_f_E_n_g_i_n_e_s for defining the functions
that generate the dynamic data.
pfGeoSets themselves can be fluxed and fluxed pfGeoSets can
be given to a pfGeode directly.
pfEngines can be used to control the data in a flux. A
complete graph of pfEngines and pfFlux can be done to
control the dynamic behavior of a database. Both pfEngines
and pfFluxes are stored in the performer binary file format
(pfb), even external functions used by pfEngines can be
registers into the pfb and the right DSO will automatically
be loaded when the pfb file will be used in Performer.
6.6.5.7 _L_i_g_h_t__P_o_i_n_t
A new light point process can be forked off and use a cpu to
do the _p_f_L_P_o_i_n_t_S_t_a_t_e computation instead of taking time of
the Draw Process. The light point process is synchronous to
the Draw process, and also support Calligraphic Light points
when the Calligraphic Board and Projector are hooked to the
system. To learn more about raster and calligraphic lights
see the pfLPointState and _p_f_C_a_l_l_i_g_r_a_p_h_i_c man pages, as well
as the pfChannel man pages to see how the light point
process works.
- 23 -
6.6.5.8 _N_e_w__l_o_a_d_e_r_s
+o Loaders for creating pfASD structures from elevation
data are now include in IRIS Performer 2.2
_l_i_b_p_f_d_b/_l_i_b_p_f_d_e_m - This loader handles a variety of the
USGS DEM elevation data products, including the common
7.5 minute (1:24,000) and 1 degree (1:250,000) DEM
files. _l_i_b_p_f_d_b/_l_i_b_p_f_d_t_e_d - This loader handles DMA
DTED Level 1 and 2 elevation data products.
_l_i_b_p_f_d_b/_l_i_b_p_f_a_r_c_i_n_f_o - This loader handles elevation
data files in the simple ARC/INFO ASCII GRID export
format. _l_i_b_p_f_d_b/_l_i_b_p_f_e_v_t - This loader reads data in
the temporary ".evt" binary format.
The loaders read the elevation data from the file and
construct an appropriate pfASD node structure. The
origin coordinates of the created pfASD node will be
set to the southwest corner, zero altitude point of the
elevation data area. The data will be oriented in the
XY plane for elevation data specified in planar
coordinates (such as UTM), or oriented properly on the
earth ellipsoid for data specified in geodetic
coordinates (Z-axis towards North Pole, X-axis defined
by the intersection of the prime meridian and
equatorial planes). Use pfdBuildASD to indicate the
levels of detail you wish to build. That is the last
parameter in pfdBuildASD().
The function "libpfdu/pfdBuildASD()" can be used to
construct pfASD structures for elevation data not
handled by the above loaders. There are support for
building paging tiles in pfdBuildASD(). It is not
turned on by default. Set the PAGING constant in
pfdBuildASD.c to 1 if you want to experiment with
paging pfASD tiles.
+o A VRML 2.0 loader is included. This loader is a gift
from DrAW Computing Associates and will successfully
the geometry and texture of many VRML2.0 files. To have
more VRML 2.0 support, such as Routes, JAVA,
saveToVrml, html direct access from performer, or to
report any problem with the VRML 2.0 loader you will
have to contact them directly at info@openworlds.com.
See the demos under openworlds in the Friend of
Performer 2.2 CD. Note that VRML 1.0 files are not
supported by this loader. Previously the case, so you
have either to convert your VRML1.0 files to VRML2.0,
or to explicitly name your files .iv so the inventor
loader will be used in place of the VRML 2.0 loader.
- 24 -
+o A OpenGL Optimizer binary file loader (csb) is part of
IRIS Performer 2.2 distribution. This allow exchange of
files in between the two products as OpenGL Optimizer
reads IRIS Performer binary files (pfb). Note that the
pfb loader for Optimizer has a problem that changes all
opaque polygons to fully transparent and vice-versa.
This will be fixed, and a new pfb loader for OpenGL
Optimizer will be available on the Web. (see section 4
of release note)
6.6.5.9 _C_o_p_l_a_n_a_r__g_e_o_m_e_t_r_y
Layer and Decal geometry may now use the new OpenGL
reference plane. Reference planes may be specified on
pfGeoSets, pfGeoStates, and in the global state. See the
pfGeoSet and pfDecal, and pfGeoState reference pages for
more information.
6.6.5.10 _T_e_x_t_u_r_e__m_a_t_r_i_c_e_s
Texture matrices may now be specified on pfGeoStates. See
the pfGeoState reference page for more information.
6.6.5.11 _T_r_a_v_e_r_s_a_l_s
libpfutil traversal, pfuTravCompileDList, traversal for
traversing an entire scene graph and creating display lists
for all pfGeoSets. This is to be used in combination with
pfuTravDListDraw and is useful for compiling and pre-
downloading display lists on InfiniteReality.
6.6.5.12 _V_i_d_e_o__t_e_x_t_u_r_i_n_g
There is one main sample program for video texturing:
/usr/share/Performer/src/pguide/libpf/C/movietex.c
a multiprocessing example. Note that all video
initialization, including the creation of video library
resources, is done in the draw process, as required by the
video library. The program has #define switches for
compilation on IRIX 6.2 or IRIX 6.5 and supports DIVO,
Sirius, OCTANE, and O2 video options. Movitex.c uses
features added in Performer 2.2: special pfTexture LOAD
source parameters for specifying dmedia buffers or the video
library server, path and drain, as well as the texture
matrix that can be specified on a pfGeoState with the
PFSTATE_TEXMAT attribute for transforming texture
- 25 -
coordinates int the proper area of a texture receiving video
input.
An old Sirius example has been retained in
/usr/share/Performer/src/pguide/libpr/C/siriusvidtex.c.
6.6.5.13 _T_e_x_t_u_r_e__L_O_D__o_b_j_e_c_t
New pfTexLOD object for controlling LOD of textures.
pfTexLOD is a new state attribute used to control the use of
levels of detail of a pfTexture. The levels of detail
accessed can be limited by setting the LOD range and the
computation of the current LOD value can be biased. These
controls are useful in conjunction with dynamic texture
loading where the accessed levels can be limited to the
valid levels and for artificially blurring or sharpening a
texture.
6.6.5.14 _N_e_w__f_a_s_t__i_m_a_g_e__f_i_l_e__f_o_r_m_a_t
There is now the pfi fast image file loader to complement
pfb. pfi files are hardware-ready fast loading image files
that may contain MIPmaps for textures and multiple complete
textures.
/usr/share/Performer/src/sample/pfconv.c
can convert a database to use pfi files for its textures. In
addition, there is a
/usr/share/Performer/src/sample/pficonv.c
for converting .rgb files to pfi files and generating
MIPmaps. Look at the data/town/town_ogl_pfi.pfb database.
6.6.5.15 _p_f_C_h_a_n_n_e_l
Here are the additional C++ member functions added in
Performer 2.2 to those already provided in IRIS Performer
2.1 for the pfChannel class. Each C++ function has a
corresponding C function, and all are fully described in the
IRIS Performer 2.2 C and C++ Reference Pages.
ggggeeeettttFFFFrrrraaaammmmeeeePPPPVVVVCCCChhhhaaaannnn
sssseeeettttOOOOuuuuttttppppuuuuttttVVVViiiieeeewwwwppppoooorrrrtttt
sssseeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
ggggeeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
sssseeeettttCCCCaaaalllllllliiiigggg
- 26 -
ggggeeeettttCCCCaaaalllllllliiiigggg
ggggeeeettttCCCCuuuurrrrCCCCaaaalllllllliiiigggg
ggggeeeettttFFFFrrrreeeeeeeeBBBBiiiinnnn
AAAASSSSDDDDAAAAttttttttaaaacccchhhh
AAAASSSSDDDDddddeeeettttaaaacccchhhh
6.6.5.16 _p_f_D_i_s_p_L_i_s_t
This is the additional C++ member function added in
Performer 2.2 to those already provided in IRIS Performer
2.1 for the pfDispList class. This function allows the
contents of one IRIS Performer pfDispList to be appended to
a second pfDispList, supporting the merge of independent
pfDispLists. The _p_f_D_i_s_p_L_i_s_t::_a_p_p_e_n_d C++ function has a
corresponding C function (_p_f_A_p_p_e_n_d_D_L_i_s_t), and both are fully
described in the IRIS Performer 2.2 C and C++ Reference
Pages.
ggggeeeettttGGGGLLLLHHHHaaaannnnddddlllleeee
sssseeeettttMMMMooooddddeeee
ccccoooommmmppppiiiilllleeee
pppprrrreeeepppprrrroooocccceeeessssssss
6.6.5.17 _p_f_Q_u_e_u_e
Here are the additional C++ member functions added in
Performer 2.2 to those already provided in IRIS Performer
2.1 for the pfQueue class. These new functions add support
for having a sort process that will sort the items in the
queue. Each C++ function has a corresponding C function,
and all are fully described in the IRIS Performer 2.2 C and
C++ Reference Pages.
ggggeeeettttEEEElllleeeemmmmeeeennnnttttSSSSiiiizzzzeeee
sssseeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
ggggeeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
ggggeeeettttSSSSoooorrrrttttMMMMooooddddeeee
sssseeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
ggggeeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
ggggeeeettttOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
ggggeeeettttSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD
iiiinnnnsssseeeerrrrttttFFFFrrrroooonnnntttt
aaaatttttttteeeemmmmppppttttRRRReeeemmmmoooovvvveeee
ssssiiiiggggnnnnaaaallllAAAAllllllllSSSSeeeerrrrvvvviiiicccceeeePPPPrrrrooooccccssss
nnnnoooottttiiiiffffyyyySSSSoooorrrrttttPPPPrrrroooocccc
6.6.5.18 _p_f_I_m_a_g_e_T_i_l_e
Here are the additional C++ member functions added in
- 27 -
Performer 2.2 to those already provided in IRIS Performer
2.1 for the pfQueue class. Each C++ function has a
corresponding C function, and all are fully described in the
IRIS Performer 2.2 C and C++ Reference Pages.
sssseeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
ggggeeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
iiiissssLLLLooooaaaaddddiiiinnnngggg
sssseeeettttPPPPrrrriiiioooorrrriiiittttyyyy
ggggeeeettttPPPPrrrriiiioooorrrriiiittttyyyy
sssseeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
ggggeeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
sssseeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
ggggeeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
sssseeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
ggggeeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
RRRReeeeaaaaddddDDDDiiiirrrreeeecccctttt
RRRReeeeaaaaddddNNNNoooorrrrmmmmaaaallll
6.6.5.19 _p_f_C_l_i_p_T_e_x_t_u_r_e
Here are the additional C++ member functions added in
Performer 2.2 to those already provided in IRIS Performer
2.1 for the pfQueue class. New functions deal with DTR,
which is a tight control on how much time you want to
allocate in the DrawProcess to dynamically load the texture
versus drawing polygons, and control of Virtual (bigger)
clip textures. Each C++ function has a corresponding C
function, and all are fully described in the IRIS Performer
2.2 C and C++ Reference Pages.
ggggeeeettttCCCCuuuurrrrCCCCeeeennnntttteeeerrrr
sssseeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt
ggggeeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt
sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
sssseeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
ggggeeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
ggggeeeettttOOOOffffffffsssseeeetttt
sssseeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
ggggeeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
sssseeeettttMMMMaaaasssstttteeeerrrr
ggggeeeettttMMMMaaaasssstttteeeerrrr
ggggeeeettttSSSSllllaaaavvvveeee
sssseeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
ggggeeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
sssseeeettttDDDDTTTTRRRRMMMMooooddddeeee
ggggeeeettttDDDDTTTTRRRRMMMMooooddddeeee
ggggeeeettttMMMMiiiinnnnDDDDTTTTRRRRLLLLOOOODDDD
- 28 -
ggggeeeettttDDDDTTTTRRRRFFFFaaaaddddeeeeCCCCoooouuuunnnntttt
sssseeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
ggggeeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
sssseeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
ggggeeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
sssseeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
ggggeeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
ggggeeeettttCCCCuuuurrrrLLLLOOOODDDDRRRRaaaannnnggggeeee
sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassss
ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassss
ggggeeeettttCCCCiiiirrrrLLLLOOOODDDDBBBBiiiiaaaassss
aaaappppppppllllyyyyMMMMeeeemmmmRRRReeeegggg
aaaappppppppllllyyyyTTTTeeeexxxxRRRReeeegggg
uuuuppppddddaaaatttteeeeMMMMeeeemmmmTTTTeeeegggg
uuuuppppddddaaaatttteeeeTTTTeeeexxxxRRRReeeegggg
uuuuppppddddaaaatttteeee
iiiinnnnvvvvaaaalllliiiiddddaaaatttteeee
aaaappppppppllllyyyyVVVViiiirrrrttttuuuuaaaallllPPPPaaaarrrraaaammmmssss
aaaappppppppllllyyyyCCCCeeeennnntttteeeerrrr
iiiissssVVVViiiirrrrttttuuuuaaaallll
6.7 _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _I_R_I_S _P_e_r_f_o_r_m_e_r _2._0 _a_n_d _p_r_e_v_i_o_u_s
_r_e_l_e_a_s_e_s
This section elucidates the changes and enhancements between
the prior IRIS Performer 2.0 release and the even older IRIS
Performer 1.2 release. Since all the 2.0 features are
included in 2.2 this concerns porting from 1.2 to 2.2 as
well.
If you are new to IRIS Performer or if you have already
converted your applications to the more recent 2.0 release
you can skip this section, since the information contained
here is provided merely to ease porting efforts for older
applications. These features are also described in the the
IRIS Performer Programming Guide.
6.7.1 _N_e_w__F_e_a_t_u_r_e_s
6.7.1.1 _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L
Performer 2.0 includes separate sets of libraries for
supporting IRIS GL or OpenGL interfaces. These libraries
have GL-dependent suffixes to indicate their type: IRIS
GL=_igl and OpenGL=_ogl
IIIIRRRRIIIISSSS GGGGLLLL:::: lllliiiibbbbppppffff____iiiiggggllll....ssssoooo
- 29 -
OOOOppppeeeennnnGGGGLLLL:::: lllliiiibbbbppppffff____ooooggggllll....ssssoooo
Porting an IRIS Performer application from IRIS GL to OpenGL
should require very little work. There are a couple of
isolated routine changes (see API changes below). The main
work will be in porting an application IRIS GL code in user
draw callbacks and in porting the windowing and event
handling to X. For porting windowing code, pfWindows and
pfPipeWindows (libpr and libpf, respectively) provide a GL
independent windowing environment. Libpfutil provides GL-
input handling utilities for libpf applications using
pfPipeWindows (pfuInitInput()). The sample programs
installed in
////uuuussssrrrr////sssshhhhaaaarrrreeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ssssrrrrcccc////ppppgggguuuuiiiiddddeeee////{{{{lllliiiibbbbpppprrrr,,,,lllliiiibbbbppppffff}}}}////pppprrrrooooggggssss
also demonstrate comparative X vs GL input handling.
When compiling for IRIS GL, use '-DIRISGL' on the command
line to include the IRIS GL versions of the Performer header
files.
6.7.1.2 _6_4_-_b_i_t__a_d_d_r_e_s_s__s_p_a_c_e__s_u_p_p_o_r_t
6.7.1.3 _P_e_r_f_o_r_m_e_r__E_n_v_i_r_o_n_m_e_n_t__V_a_r_i_a_b_l_e_s__a_n_d__D_S_O_s
Performer now robustly supports the notion of separate run-
time file loaders as DSO's (Dynamic Shared Objects). Thus,
the generic utility method for opening a file now differs
considerably - the extension of the filename is used to
determine the name of shared object to load as well as the
function within that shared library to call. Two new
environment variables exist to help locate these dynamic
shared object libraries at run-time:
+o PFLD_LIBRARY_PATH Specifies a colon separated list of
directories where Performer should look for dynamic
objects...
+o PFHOME Specifies the root Performer directory (the root
used to install Performer). This is used such that
various code in the libraries can look relative to this
top level such as $PFHOME/usr/lib/libpfdb might be a
location where dso's would live. In this way a
consistent tree structure might be maintained
regardless of Performers PFHOME directory. (This is
useful when using Performer installed on another
automounted machine for instance - setenv PFHOME
/hosts/remote_machine/)
- 30 -
6.7.1.4 _C_+_+__A_P_I
When compiling programs using Performer's C++ API, you need
to directly include the class header files from
////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////pppprrrr
and
////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffff....
6.7.1.5 _C_o_m_p_i_l_i_n_g _P_e_r_f_o_r_m_e_r _1._2 _C++ _a_p_p_l_i_c_a_t_i_o_n_s _w_i_t_h
_P_e_r_f_o_r_m_e_r _2._0 With Performer 2.0, compiling a Performer
application with the C++ compiler enables the use of C++
classes for Performer types. Some of these Performer types
(pfMatrix, pfVec2, pfVec3, pfVec4, pfQuat) are typedefed
arrays when compiling with C and classes when compiling with
C++. Because typedefed arrays and classes differ in their
usage, Performer applications written C++ using Performer
1.2's C API may not compile under C++ unless Performer is
told to revert to C types when compiling under C++.
If you wish to compile existing C++ code using Performer C
types add the line
''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCCPPPPLLLLUUUUSSSSPPPPLLLLUUUUSSSS____AAAAPPPPIIII 0000''''
before including any Performer header files. Note that the
use of C types precludes the use of Performer's C++ API.
6.7.1.6 _M_i_x_i_n_g__C_+_+__A_P_I__a_n_d__C__A_P_I__i_n__a__S_i_n_g_l_e__A_p_p_l_i_c_a_t_i_o_n
Normally, when compiling under C++, the C API routines
corresponding to member functions on a class are not exposed
in the header files. Applications wishing to taste the
combined smorgasbord of both APIs should add the line
''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCC____AAAAPPPPIIII 1111
before including any Performer header files.
6.7.2 _L_I_B_P_R__E_n_h_a_n_c_e_m_e_n_t_s
6.7.2.1 _p_f_G_e_o_S_e_t
PFGS_POLYS for N-sided, convex polygons. Specify the number
of sides of each polygon with pfGSetPrimLengths().
pfGSetPassFilter() sets a filter which allows only specific
pfGeoSets to be drawn, e.g., a
- 31 -
PPPPFFFFGGGGSSSS____NNNNOOOONNNNTTTTEEEEXXXX____GGGGSSSSEEEETTTT |||| PPPPFFFFGGGGSSSS____EEEEMMMMIIIISSSSSSSSIIIIVVVVEEEE____GGGGSSSSEEEETTTT
filter will draw only non-textured, emissive pfGeoSets.
pfGetGSetAttrRange() returns the number of attributes (e.g.,
coordinates) accessed by non-indexed a pfGeoSet and the
maximum range of indexes if the pfGeoSet is indexed.
pfGeoSets can now index their pfGeoStates through a global
table set by pfApplyGStateTable(). pfGSetGStateIndex() sets
the value which is used to index the global table. Indexed
pfGeoStates in conjunction with different pfGeoState tables
allow drastically different appearances of a single database
without duplicating geometry or the scene graph. For
example, a visual and infrared version of a database is
easily supported with 2 different pfGeoState tables.
pfGeoSets now accept pfCycleBuffer* as attribute lists to
support dynamic attribute changes in a pipelined,
multiprocessing environment. pfCycleBuffers automatically
manage multiple data buffers to avoid data collisions and
ensure frame-accurate behavior of attribute changes. This
greatly simplifies modification of coordinates for
sophisticated facial and skeletal animation, geometrically
morphed level-of-detail, and special effects such as
explosions. Note that pfCycleBuffer nodes are obsolete with
IRIS Performer 2.2 and that pfFlux should be used instead of
pfCycleBuffer.
6.7.2.2 _p_f_G_e_o_S_t_a_t_e
pfGStateFuncs() allow pre and post callbacks on a per-
pfGeoState basis. The pre callback is invoked after the GL
has been configured with the pfGeoState's state and the post
callback is lazily invoked by the next pfGeoState
application so the pre/post callbacks nicely bracket
pfDrawGSet().
pfGStateVal() is added for floating point values and now
accepts PFSTATE_ALPHAREF.
pfGeoSets can now index pfGeoStates (pfGSetGStateIndex())
through pfGeoState global tables (pfApplyGStateTable()) or
pfGeoState tables assigned to a pfChannel
(pfChanGStateTable()) .
6.7.2.3 _p_f_F_o_g
pfGetFogDensity returns the density of a pfFog at a given
range.
- 32 -
6.7.2.4 _p_f_L_P_o_i_n_t_S_t_a_t_e
A new PFSTATE attribute, pfLPointState causes pfGeoSets of
type PFGS_POINTS to be rendered as "light points", e.g.,
runway lights, stars. Light points have perspective size
based on range and many other features. This is a major
enhancement and is discussed in great detail in the
pfLPointState man page.
6.7.2.5 _p_f_S_p_r_i_t_e
A new kind of transform, pfSprite automatically rotates
pfGeoSets and plain GL geometry to face the viewer.
Different rotational constraints are possible including:
rotate about an axis, rotate about a point.
6.7.2.6 _p_f_T_e_x_G_e_n
A new PFSTATE attribute, pfTexGen encapsulates the GL's
texgen() feature which automatically generates texture
coordinates. The Wavefront OBJ file loader in libpfdb
provides an example of the use of this new capability. Refer
to that source code for usage examples.
6.7.2.7 _p_f_T_r_a_n_s_p_a_r_e_n_c_y
pfTransparency now supports PFTR_MS_ALPHA_MASK which enables
multisample transparency but also writes the true alpha
value into the frame buffer instead of fully opaque alpha
values as PFTR_MS_ALPHA does.
6.7.2.8 _p_f_D_e_c_a_l
When using DISPLACE type decals, LAYERS are no longer
required to be rendered immediately after their BASES - they
can be drawn in any order. This introduces new LAYER-
specific tokens: PFDECAL_LAYER_FAST, PFDECAL_LAYER_DISPLACE
and requires specific identification of all layers after the
first since each layer must be displaced slightly more than
its predecessor. The tokens PFDECAL_LAYER_1 ->
PFDECAL_LAYER_7 are provided for layer identification.
6.7.2.9 _p_f_C_y_c_l_e_B_u_f_f_e_r_/_p_f_C_y_c_l_e_M_e_m_o_r_y
Note that pfCycleBuffer is obsolete with IRIS Performer2.2
in favor of the pfFlux. IRIS Performer 2.0/2.1 pfCycleBuffer
are still included in IRIS Performer 2.2.
A new kind of pfMemory, pfCycleBuffer supports changing data
in a pipelined, multiprocessing environment while
maintaining data exclusion and frame-accurate behavior. A
- 33 -
pfCycleBuffer manages a set of buffers called pfCycleMemorys
and "rotates" them each frame, advancing the data
modifications cleanly down the processing pipeline. libpf
transparently handles the buffer rotations.
6.7.2.10 _p_f_P_o_l_y_t_o_p_e
A pfPolytope is a set of N half spaces whose intersection
defines a possibly semi-infinite, convex volume which is
useful for culling and intersection testing where a tighter
bound than a pfSphere, pfBox, pfCylinder, pfFrustum is of
benefit.
6.7.2.11 _p_f_G_L_O_v_e_r_r_i_d_e
Adds the ability to force the use of a particular GL
mechanism to implement a libpr feature.
6.7.2.12 _p_f_N_o_t_i_f_y
pfNotify has been enhanced with new formatting and modes
(PFNFY_MORE). Refer to the pfNotify man page for full
details.
6.7.2.13 _p_f_G_e_t_T_i_m_e
New functions. Refer to the reference pages for further
information.
ppppffffWWWWrrrraaaappppCCCClllloooocccckkkk
ppppffffCCCClllloooocccckkkkNNNNaaaammmmeeee
ppppffffCCCClllloooocccckkkkMMMMooooddddeeee
6.7.2.14 _W_i_n_d_o_w__S_y_s_t_e_m__R_o_u_t_i_n_e_s
New window-system interface functions provide a single API
for creating and managing windows that works across the IRIS
GL, IRIS GLX Mixed Mode, and OpenGL-X environments. Window
system independent types have been provided to match the X
Window System types to provide complete portability between
the IRIS GL and OpenGL-X windowing environments.
6.7.2.15 _p_f_Q_u_e_r_y_F_e_a_t_u_r_e_/_p_f_Q_u_e_r_y_S_y_s
New QueryFeature routines determine the presence, absence,
or limitations of features in the underlying graphics
implementation, like the availability of attenuation in the
lighting model or the availability of multiple graphics
pipes.
- 34 -
The QuerySys routines determine the capacity and limitations
of the underlying graphics implementation, like the size of
texture memory or the number of stencil planes available.
6.7.2.16 _p_f_T_e_x_t_u_r_e__e_x_t_e_n_s_i_o_n_s
6.7.2.17 _I_n_t_e_g_r_a_t_e_d__T_e_x_t__S_u_p_p_o_r_t
Two and Three dimensional font rendering is supported by the
new pfFont (libpr), pfString (libpr), and pfText (libpf)
primitives.
The pfFont facility provides the capability to load fonts
for 3-D rendering with the string drawing routines from
pfString and pfText. IRIS Performer uses this facility to
provide flat, extruded, and textured-quad fonts in three
dimensions.
pfString provides a pfGeoSet like facility for encapsulating
geometry to display a string in 3-D with attributes such as
color, arbitrary transformation matrix, and font (see
pfFont).
A pfText node is a list of pfStrings much as a pfGeode is a
list of pfGeoSets. The two APIs are also similar - a new
pfText node can be created and the list of pfStrings
attached to it can be manipulated by addition, insertion,
removal or replacement.
The best examples of these new font tools at present are
hello.c and helloC.C, both provided in the IRIS Performer
source directory.
6.7.2.18 _p_f_Q_u_a_t
A full set of quaternion utilities is defined in prmath.h
and is documented in the pfQuat man page.
6.7.3 _L_I_B_P_F__E_n_h_a_n_c_e_m_e_n_t_s
6.7.3.1 _M_u_l_t_i_p_l_e__W_i_n_d_o_w_s__o_n__a__s_i_n_g_l_e__p_f_P_i_p_e
Multiple windows can now be rendered from a single pfPipe.
This allows a single drawing process to render to multiple
windows on a single screen. Libpf now requires use of the
pfPipeWindow primitive for opening windows for pfPipes. See
the pfWindow and pfPipeWindow (pfConfigPWin()) reference
pages for details.
- 35 -
6.7.3.2 _p_f_M_o_r_p_h
Note that pfMorph node is obsolete in 2.2. We recommand
using pfFlux/pfEngines instead of pfCycleBuffer and pfMorph
feature.
pfMorph is a new group node intended for automatic morphing
of pfGeoSet attributes: colors, normals, coordinates, and
texture coordinates but which can morph any floating point
values. pfMorph is triggered during the new APP traversal
and linearly combines N source arrays into a single
destination which is typically a pfCycleBuffer used as a
pfGeoSet attribute array. By modifying the source weights
each frame, the application can produce sophisticated,
frame-accurate effects such as facial and skeletal animation
and morphed, geometric level-of-detail.
6.7.3.3 _p_f_D_B_a_s_e
The DBASE process is a new addition to the IRIS Performer
multiprocessing family. It is similar to the ISECT process
in that it can run asynchronously with respect to the main
processing pipeline (APP->CULL->DRAW). Callback and trigger
functions, pfDBaseFunc() and pfDBase() respectively, allow
explicit control and customization of the DBASE function.
The DBASE is intended for asynchronous database processing,
particularly paging to and from disk when using large
databases. Note that IRIS Performer does not provide a
paging facility directly - rather it provides the tools
which the application can use to implement database paging.
Database deletions are carried out in pfDBase() and do not
slow down the synchronous pipeline if DBASE is configured as
a separate process.
6.7.3.4 _p_f_B_u_f_f_e_r
pfBuffer is the primary tool for asynchronous database
manipulations. A pfBuffer isolates database changes to a
given process, avoiding dangerous data collisions with other
processes when multiprocessing. Scene graphs built in an
asynchronous process, such as the DBASE, do not affect the
synchronous, real-time APP->CULL->DRAW pipeline and are
quickly and safely merged into the main processing stream
with pfMergeBuffer().
6.7.3.5 _p_f_M_u_l_t_i_t_h_r_e_a_d
pfMultithread adds a new multiprocessing dimension by
multithreading a given IRIS Performer processing stage.
Currently, only the CULL stage may be multithreaded such
that thread culls a pfChannel. This is expected to be very
- 36 -
useful for MCO applications where many pfChannels per pipe
cause the CULL stage to become a bottleneck.
6.7.3.6 _P_F_T_R_A_V___A_P_P
PFTRAV_APP is a new automated IRIS Performer traversal
intended for behavior computation, event distribution and
other application level functions. It is carried out in the
APP process and is initiated directly by pfAppFrame() or
automatically by pfSync(). A wrapper callback and callback
data (pfAppFunc(), pfPassAppData()) and node callbacks and
data (pfNodeTravFuncs(), pfNodeTravData()) provide
application extensibility similar to that offered for the
CULL, DRAW, and ISECT traversals.
6.7.3.7 _p_f_C_h_a_n_D_a_t_a
pfChannel passthrough data may be supplied by the
application with pfChanData() rather than allocated by the
pfChannel with pfAllocChanData(). This allows pfChannels to
share a single passthrough data block.
6.7.3.8 _p_f_C_h_a_n_C_u_l_l_P_t_o_p_e
pfChanCullPtope() specifies that a pfChannel use a
pfPolytope, rather than its viewing pfFrustum, for culling.
This allows highly customized culling for specific
environments where visibility can be predetermined to some
extent, e.g., when in a room and looking through a door the
cull volume can be shrunk to the door opening.
6.7.3.9 _p_f_C_h_a_n_N_o_d_e_I_s_e_c_t_S_e_g_s
pfChanNodeIsectSegs() is identical to pfNodeIsectSegs() but
includes a pfChannel to evaluate pfLODs during the
intersection traversal. Thus, pfChanNodeIsectSegs()
computes intersections with the same level-of-detail as is
selected for rendering. This greatly simplifies operations
such as terrain following on terrain which is modeled as
levels-of-detail.
6.7.3.10 _p_f_C_h_a_n_G_S_t_a_t_e_T_a_b_l_e
pfChannels can provide a pfGeoState table which is accessed
by indexed pfGeoSets. This simplifies the management of
multiple views of a single database, such as infrared vs.
out-the-window.
- 37 -
6.7.3.11 _p_f_V_i_d_e_o_R_a_t_e
In release 1.2, IRIS Performer internally computed the rate
of the video clock. In 2.0, IRIS Performer now queries the
video microcode for the video retrace rate or accepts the
rate set by the application with pfVideoRate().
6.7.3.12 _p_f_C_o_n_f_i_g_S_t_a_g_e
pfStageConfigFunc() allows the specification of an
initialization callback for each IRIS Performer processing
stage. pfConfigStage() invokes specified initialization
callbacks in the appropriate processes at the next
pfFrame(). Initialization callbacks typically establish the
initial conditions of a process. Examples include setting
non-degrading priorities and locking processes to CPUs for
real-time applications and downloading textures in the DRAW
stage.
6.7.3.13 _p_f_L_o_o_k_u_p_N_o_d_e
pfLookupNode() extends pfFindNode by searching for a path-
named node of a particular type, beginning at a specific
node. This greatly simplifies finding named parts of a
pfCloned subgraph.
6.7.3.14 _p_f_S_c_e_n_e_G_S_t_a_t_e
pfScenes can now reference a pfGeoState that defines the
"global state" which may be inherited by other pfGeoStates
within the scene.
6.7.3.15 _p_f_G_e_t_S_C_S_M_a_t_P_t_r__a_n_d__p_f_G_e_t_D_C_S_M_a_t_P_t_r
pfGetDCSMatPtr() returns a pointer to the pfDCS matrix for
fast access. Likewise, pfGetSCSMatPtr() returns a pointer to
the pfSCS matrix.
6.7.3.16 _N_e_w__G_L_-_i_n_d_e_p_e_n_d_e_n_t__W_i_n_d_o_w_i_n_g__U_t_i_l_i_t_i_e_s
IRIS Performer now provides utilities for opening, closing,
and managing windows. The same routines will manage pure
IRIS GL windows, IRIS GL-X Mixed-Mode, and OpenGL-X windows.
Libpf application will now use the new pfPipeWindow for
opening IRIS Performer windows. See the pfWindow (libpr)
and pfPipeWindow (libpf) (pfConfigPWin()) reference pages
for details.
6.7.3.17 _A_P_I__C_h_a_n_g_e_s
pfSelectCtab() is now pfApplyCtab()
pfGetMallcoSize() is now pfGetSize()
- 38 -
pfGetHyperId() is now pfGetPipeHyperId()
6.7.3.18 _R_e_f_e_r_e_n_c_e__C_o_u_n_t_i_n_g
All pfObjects, including pfNodes now have a reference count.
A pfGroup increments the reference count of all its
children.
6.7.3.19 _M_o_d_e__Q_u_e_r_y__S_e_m_a_n_t_i_c_s
pfGetGStateAttr/Mode do not return the global values of
inherited state elements. Instead NULL and -1 are returned.
Use pfGetCurGStateAttr/Mode for 1.2 behavior.
6.7.3.20 _V_i_d_e_o__C_l_o_c_k
pfInitVClock() no longer starts and stops the video clock.
Instead, use pfStart/StopVClock() to start and stop video
interrupts. pfStart/StopVClock are only necessary for
VGX/VGXT graphics and are ignored on other graphics.
6.7.3.21 _p_f_P_i_p_e_S_c_r_e_e_n
Proper multipipe operation now requires that pipes be
assigned a screen (pfPipeScreen) before the first pfFrame().
Otherwise, pipes will be automatically assigned a screen.
6.7.3.22 _p_f_E_v_a_l_u_a_t_e_L_O_D
pfEvaluateLOD() returns a floating point number indicating
which child is selected by a given pfChannel. The fractional
portion of the number is used for fading transitions.
6.7.3.23 _p_f_L_O_D_S_t_a_t_e
pfLODStates are used to specify how individual LOD's or
groups of LODs will respond to stress and range.
pfLODStates can either be explicitly set per LOD or set as
an index into a list of pfLODStates provided to a pfChannel.
Thus pfLODStates can make the same pfLOD behave differently
in different channels as well as differently under different
stress conditions. pfLODStates ultimately modify the range
and fade transition calculations made by performer when
culling. See pfLODState, pfLOD, and pfChannel.
6.7.3.24 _p_f_L_O_D__e_n_h_a_n_c_e_m_e_n_t_s
pfLODs now support per-pair transition zones for fade LOD
See the pfLODTransition reference page.
pfLODs now respond to stress by scaling LOD ranges and
- 39 -
transition zones and take a pfLODState structure to describe
the desired stress behavior of a pfLOD. See the pfLODState
reference page.
LOD Priority Classes can be formed by the sharing of
pfLODState structures across a set of LODs.
Per-Channel LOD Priority Classes can be formed by assigning
pfChannels with tables of pfLODStates and assigning pfLODs
an index into these tables. See the pfChanLODAttr and
pfLODLODStateIndex reference pages.
6.7.4 _l_i_b_p_f_d_u__E_n_h_a_n_c_e_m_e_n_t_s
6.7.4.1 _O_p_t_i_m_i_z_i_n_g__S_c_e_n_e__B_u_i_l_d_e_r__f_o_r__u_s_e__i_n__F_i_l_e__L_o_a_d_e_r_s
Performer 2.0 contains a new layer of support for easily
converting databases from external formats into performer
runtime structures. This new layer is called libpfdu which
stands for library of performer database utilities. The
pfdBuilder contains mechanisms for completely converting
external database formats and data into efficient IRIS
performer structures. The builder will take care of state
sharing and sort your geometry by state. Collections of
graphics state and geometry are given to the pfdBuilder as a
database is read in. At the end of reading a database file,
a pfNode containing an efficient Performer representation of
the database can be obtained. This new API supersedes the
previous pfuBuilder which was a simple interface for
encapsulating geometric data into performer structures in an
intuitive way. This new layer of support is built on top of
and is a superset of the previous pfuBuilder (which has now
become the pfdGeoBuilder) that was released with Performer
1.2. Check out
////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffffdddduuuu....hhhh
for mode settings and api for the new extended builder.
libpfdu is the Performer library of database utilities. Its
purpose is to provide helpful functions for constructing
optimized Performer data structures and scene graphs. It is
used mainly by database loaders which take an external file
format containing 3d geometry and graphics state and load
them into Performer optimized run-time only structures.
Note that these utilities often prove very useful as most
modeling tools and file formats represent their data in
structures that correspond to the way users model data and
these data structures are often necessarily mutually
exclusive with effective and efficient Performer run-time
- 40 -
structures. libpfdu contains many utilities including dso
support for database loaders and their modes, file path
support, etc, but the heart of libpfdu is the notion of the
Performer database 'builder' - pfdBuilder.
The builder is a tool to allow users to input/output a
collection of geometry and graphics state in immediate mode
fashion (similar to Open/Iris GL). Data is inputed to the
builder one geometric primitive at a time along with its
corresponding graphics state. When all of the data has been
inputed, the user simply requests optimized Performer data
structures which can then be used as a part of a Performer
Scene Graph. The builder hashs geometry into different
'bins' based on the geometry's attribute binding types and
associated graphics state. It also keeps track of graphics
state elements (textures,materials,light models, fog,etc)
and shares state elements whenever possible. In the end,
the builder will create Performer 'pfGeoSets' that contain
triangle meshes created by running the original geometry
through the libpfdu tmeshing utility. To go along with each
pfGeoSet, the builder builds up a Performer pfGeoState
(Performer's encapsulated state primitive) which has been
optimized to share as many attributes as possible with other
pfGeoStates being build (and possibly even with a more
global pfChannelGState). Having created all of these
Performer primitives (pfGeoSets and pfGeoStates) the builder
will place them in a Performer leaf node (pfGeode), and
possibly even artificially create a spatial hierarchy by
running the new database through a spatial breakup utility
function which is also contained in libpfdu. Note that this
builder should also allow the user to extend the notion of a
'graphics state' by registering callback functionality
through builder api and then treating this
state/functionality like any other Performer state/mode
(although such uses of the builder are of course at least
slightly more complicated).
In short libpfdu is a collection of utilities that
effectively act as a data funnel where users input flattened
3d graphics information and are given in return fully
functional and hopefully well optimized Performer run-time
structures.
6.7.5 _l_i_b_p_f_d_b__E_n_h_a_n_c_e_m_e_n_t_s
6.7.5.1 _N_e_w__F_i_l_e__F_o_r_m_a_t_s OpenInventor 2.0 file support.
This is a completely new loader that uses OpenInventor
traversal of the input scene graph to create the Performer
scene graph, allowing robust conversion of all geometry.
- 41 -
AutoDesk 3DStudio file support using the 3dsftk.
Side Effects Software Prisms (.poly and .bpoly) file
support.
Medit Productions Medit (.medit) file support
S1000 file support, based on code from Texas Instruments.
Several other formats. Look in libpfdb for the complete
list.
6.7.6 _S_t_r_u_c_t_u_r_a_l__C_h_a_n_g_e_s
6.7.6.1 _C_l_a_s_s__s_t_r_u_c_t_u_r_e
One of the major differences from 1.2 is that libpr is now
written in C++ and the class tree has changed. 1.2 had both
a prObject and pfObject - now there is a single pfObject
which is derived from IRIS Performer's base class, pfMemory.
There are no more pr-prefixed routines which were used for
libpr->libpf inheritance, e.g, pfLight -> pfLightSource.
6.7.6.2 _p_f_T_y_p_e
IRIS Performer has changed its type system to support new,
application-derived types. pfGetType() now returns a pfType*
instead of a bitmask. Each IRIS Performer data type which
has an explicit allocator (usually pfNew*()) has an
associated pfType which is created at initialization time by
pfInit(). The pfType corresponding to a particular class is
returned by pfGet<*>ClassType(), e.g.,
pfGetGroupClassType().
The primary difference in 2.0 is the fact that types are no
longer represented with bitmasks where the inheritance chain
of a particular type is encoded in the bitmask, e.g.,
PFTYPE_SCS == (100 | PFCLASS_SCS | PFCLASS_GROUP |
PFCLASS_NODE), indicating that SCS is derived from pfGroup
and pfNode. pfType is an opaque data structure whose
inheritance chain must be queried through pfIsOfType().
Here are the old and new methods for testing an object for
exact type equality. The 1.2 method:
iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== PPPPFFFFTTTTYYYYPPPPEEEE____SSSSCCCCSSSS))))
and the 2.0 methods, which are equivalent
iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))
- 42 -
iiiiffff ((((ppppffffIIIIssssEEEExxxxaaaaccccttttTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))
Here are the old and new methods for testing an object for
derivation from a give type. The 1.2 method:
iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) &&&& PPPPFFFFCCCCLLLLAAAASSSSSSSS____GGGGRRRROOOOUUUUPPPP))))
and the 2.0 method
iiiiffff ((((ppppffffIIIIssssOOOOffffTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttGGGGrrrroooouuuuppppCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))
Special care should be taken when porting to the new type
API.
6.7.7 _C_h_a_n_g_e_s__i_n__l_i_b_p_r
6.7.7.1 _D_e_f_a_u_l_t__E_n_a_b_l_e_s
PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
by default. Databases created with loaders that assumed
specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
be rendered improperly. All IRIS Performer loaders shipped
with 2.0 create pfGeoStates that assume the global default
is the same as that set by pfBasicState(), i.e., everything
is OFF.
6.7.7.2 _L_i_n_e__W_i_d_t_h__a_n_d__P_o_i_n_t__S_i_z_e
pfGeoSets with linewidth/pointsize of <= 0 will not set
linewidth or pointsize but will inherit it through the GL.
6.7.7.3 _A_l_p_h_a__R_e_f_e_r_e_n_c_e__V_a_l_u_e
The PFSTATE_ALPHAREF state element has changed from an
integer in the range 0-255 to a float in the range 0-1 and
is now set on pfGeoStates with the new routine, pfGStateVal.
A warning will be generated if set through pfGStateMode.
6.7.7.4 _D_e_c_a_l__I_m_p_l_e_m_e_n_t_a_t_i_o_n
pfDecal no longer sets zwritemask to 0 when drawing
displaced layers. This allows layers to be drawn separately
from their bases, enabling improved sorting by graphics
mode.
6.7.7.5 _M_a_t_h__F_u_n_c_t_i_o_n_s
pfXformPt3/Vec3 previously considered the last column of the
matrix and divided by the homogeneous coordinate, w. The new
pfXformPt3/Vec3 are much faster and treats the pfMatrix as a
4x3 matrix. The old behavior is now accessed through the
- 43 -
new pfFullXformPt3/Vec3 routines.
pfInvertMat is now named pfInvertFullMat but a #define
ensures 1.2 compatibility.
pfMakeRotOntoMat is obsoleted in favor of the much faster
pfMakeVecRotVecMat which assumes normalized input vectors.
6.7.7.6 _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
pfFrustAspect is no longer persistent. In 1.2, automatic
frustum calculation (e.g. PFFRUST_CALC_HORIZ) was always in
effect once set. In 2.0, pfFrustAspect recomputes the
frustum only at time of invocation.
6.7.8 _C_h_a_n_g_e_s__i_n__l_i_b_p_f
6.7.8.1 _D_e_f_a_u_l_t__E_n_a_b_l_e_s
PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
by default. Databases created with loaders that assumed
specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
be rendered improperly. All IRIS Performer loaders shipped
with 2.0 create pfGeoStates which assume the global default
is the same as that set by pfBasicState(), i.e., everything
is OFF. To achieve 1.2 behavior with 1.2 loaders, call the
following in the DRAW process after the window is opened:
ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____LLLLIIIIGGGGHHHHTTTTIIIINNNNGGGG))));;;;
////**** OOOOnnnnllllyyyy oooonnnn IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy////RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee////IIIImmmmppppaaaacccctttt////VVVVGGGGXXXXTTTT////VVVVGGGGXXXX ****////
ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____TTTTEEEEXXXXTTTTUUUURRRREEEE))));;;;
ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____FFFFOOOOGGGG))));;;;
6.7.8.2 _M_u_l_t_i_-_c_h_a_n_n_e_l__f_o_g__a_n_d__l_i_g_h_t_i_n_g__c_o_n_s_i_s_t_e_n_c_y
pfChannels now encode rotational offsets (pfChanViewOffsets)
in the ModelView instead of the Projection matrix.
Consequently, fog always matches across adjacent pfChannels
but for proper lighting, a local viewer lighting model is
required (pfLModelLocal).
6.7.8.3 _T_y_p_e__i_n_h_e_r_i_t_a_n_c_e
Multiple inheritance through the C API is gone. Previously,
pfChannels could use pfFrustum API, e.g.,
pfMakePerspFrust(chan,...) pfFrameStats could use pfStats
API, and pfLightSources could use pfLight API, e.g.,
pfLightPos(lsource...). Additional routines are now provided
to maintain the same functionality without the complexities
of multiple inheritance. The new routines name are simply
- 44 -
the old routines where the "base" class name is replaced
with the "derived" class name. For example, pfMakePerspFrust
becomes pfMakePerspChan and pfLightPos becomes pfLSourcePos.
Comprehensive tables illustrating the correspondence between
routine names are found in pfChannel, pfFrameStats, and
pfLightSource man pages.
6.7.8.4 _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
Customizing a viewing frustum with pfMakePerspChan or
pfMakeOrthoChan now disables the automatic viewport aspect
ratio matching feature of pfChannel (pfChanAutoAspect).
6.7.8.5 _A_P_I__C_h_a_n_g_e_s
pfChanCullFunc and pfChanDrawFunc are now subsumed by
pfChanTravFunc.
pfStageConfigFunc() and pfConfigStage() replace the now
obsolete pfInitPipe().
6.7.8.6 _B_u_g__f_i_x
PFPHASE_FLOAT and PFPHASE_LOCK now work in single process
mode.
6.7.8.7 _p_f_S_w_i_t_c_h__s_e_m_a_n_t_i_c_s
pfSwitchVal() used to determine the validity of the switch
value which was problematic if no children had been added to
the pfSwitch yet. The validity check is now deferred to
individual traversal routines.
6.7.8.8 _p_f_D_a_t_a_P_o_o_l_s
When Performer shared memory has been created, pfDataPools
are now positioned in the virtual address space so that
conflicts are less likely to arise. Such conflicts were a
frequent cause of failures of pfAttachDPool. Deleting a
data pool now detaches it from the address space.
6.7.8.9 _p_f_P_a_r_t_i_t_i_o_n_s
Allow better specification of the spacing and positioning of
the spatial partition to reduce construction time. They also
work now.
6.7.8.10 _O_t_h_e_r__C_h_a_n_g_e_s
- 45 -
6.7.8.11 _E_l_i_m_i_n_a_t_i_o_n__o_f__m_u_l_t_i_p_l_e__i_n_h_e_r_i_t_a_n_c_e
The CAPI inheritance of pfChannel from pfFrustum,
pfLightSource from pfLight and pfFrameStats from pfStats has
been removed. API has been added on the formerly derived to
duplicate the functionality of the former base class, e.g.
pfApplyFrust(chan) -> pfApplyChan(chan).
6.7.8.12 _L_i_g_h_t__M_o_d_e_l__A_t_t_e_n_u_a_t_i_o_n__v_s__L_i_g_h_t__A_t_t_e_n_u_a_t_i_o_n
IRIS GL: Light Attenuation is on the pfLightModel
vvvvooooiiiidddd ppppffffLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;
vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;
OpenGL: Light Attenuation is on the pfLight
vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;
vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;
6.7.8.13 _p_f_A_l_p_h_a_F_u_n_c__n_o_w__t_a_k_e_s__a__f_l_o_a_t__f_o_r__r_e_f
wwwwaaaassss:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;
nnnneeeewwww:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;
6.7.8.14 _p_f_G_e_t_A_l_p_h_a_F_u_n_c__n_o_w__r_e_t_u_r_n_s__a__f_l_o_a_t__f_o_r__r_e_f
wwwwaaaassss:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;
nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;
6.7.8.15 _p_f_G_S_t_a_t_e_M_o_d_e__a_n_d__p_f_G_e_t_G_S_t_a_t_e_M_o_d_e
pf{Get}GStateMode can no longer accept the PFSTATE_ALPHAREF
token. Use
ppppffffGGGGSSSSttttaaaatttteeeeVVVVaaaallll((((ggggssssttttaaaatttteeee,,,, PPPPFFFFSSSSTTTTAAAATTTTEEEE____AAAALLLLPPPPHHHHAAAARRRREEEEFFFF,,,, vvvvaaaallll))));;;;
6.7.8.16 _p_f_L_i_g_h_t_C_o_l_o_r__a_n_d__p_f_G_e_t_L_i_g_h_t_C_o_l_o_r
pfLightColor and pfGetLightColor now take arguments to
specify which color.
wwwwaaaassss:::: ppppffffLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaannnndddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaarrrreeee oooobbbbssssoooolllleeeetttteeee....
nnnneeeewwww:::: vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
ffffllllooooaaaatttt rrrr,,,, ffffllllooooaaaatttt gggg,,,, ffffllllooooaaaatttt bbbb))));;;;
- 46 -
nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
ffffllllooooaaaatttt**** rrrr,,,, ffffllllooooaaaatttt**** gggg,,,, ffffllllooooaaaatttt**** bbbb))));;;;
6.7.8.17 _p_f_I_n_i_t_G_f_x
pfInitGfx() has changed API, location and behavior:
wwwwaaaassss:::: vvvvooooiiiidddd ppppffffIIIInnnniiiittttGGGGffffxxxx((((ppppffffPPPPiiiippppeeee ****pppp))));;;;
nnnneeeewwww:::: ppppffffIIIInnnniiiittttGGGGffffxxxx((((vvvvooooiiiidddd))));;;;
pfInitGfx() should now be used to initialize all pfWindows
and pfPipeWindows.
6.7.8.18 _p_f_I_n_i_t_G_L_X_G_f_x
pfInitGLXGfx(pfPipe *) has been removed. Use the
pfPipeWindow utilities.
6.7.8.19 _p_f_G_e_t_P_i_p_e_W_i_n__a_n_d__p_f_G_e_t_P_i_p_e_G_L_X_W_i_n_s
pfGetPipeWin and pfGetPipeGLXWins have been removed. There
is now pfGetPipePWin() to support this functionality.
6.7.8.20 _p_f_I_n_i_t_P_i_p_e
pfInitPipe() is obsoleted in favor of pfStageConfigFunc()
and pfConfigStage(). pfInitPipe() no longer is used to
create windows. Use pfConfigPWin for a window
initialization callback. Use pfConfigStage for initializing
(or later re-configuring) the CULL or DRAW processes
(stages) for a given pipe.
6.7.8.21 _p_f_G_e_t_P_i_p_e_O_r_i_g_i_n
pfGetPipeOrigin() has been removed. Use pfGetWinOrigin() or
pfGetPWinOrigin() to get the size of a pfWindow or
pfPipeWindow respectively.
6.7.8.22 _p_f_G_e_t_P_i_p_e_S_i_z_e
pfGetPipeSize() now returns the screen size of a pfPipe. Use
pfGetWinSize() or pfGetPWinSize() to get the size of a
pfWindow or pfPipeWindow respectively.
6.7.8.23 _p_f_u_W_i_d_g_e_t_F_u_n_c__r_e_n_a_m_e_d
pfuWidgetFunc() is now pfuWidgetActionFunc().
- 47 -
6.7.8.24 _p_f_u_E_n_a_b_l_e_P_a_n_e_l
pfuEnablePanel() no longer takes an enable argument.
Instead, pfuPanels are enabled/disabled with
pfuEnablePanel() and pfuDisablePanel() respectively.
6.7.8.25 _p_f_u_G_e_t_P_a_n_e_l_S_i_z_e
pfuGetPanelSize now follows standard convention of (xo, yo,
xs, ys) parameter ordering.
wwwwaaaassss:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****yyyyssss))));;;;
nnnneeeewwww:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllOOOOrrrrggggSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyssss))));;;;
6.7.8.26 _p_f_I_n_i_t_P_W_i_n
pfInitPWin is now pfConfigPWin